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ABSTRACT 
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particular  domain  and  Its  dl a l opue-dr  l  ven  acquisition  of  the 
domain  to  produce  a  Loose  Model;  second,  the  Informal  and 
typically  I l l -structured  manner  In  which  both  this  Loose 
Model  and  the  task  to  be  programmed  are  specified  and  their 
translation  Into  a  directly  Interpretable  Precise  Model. 

Throughout  the  system,  knowledge  Is  represented  by 
tuples,  and  structured  byt  a  theory  of  domains  and  their 
model  Interrelationships;  a  strong  notion  of  types;  and  tfe 
use  of  constraints  on  all  arguments  of  the  tuples.  Use  of 
compound  expressions,  enabling  the  Intermixing  of  patterns 
to  be  Instantiated  with  expressions  to  be  evaluated,  greatly 
simplifies  program  control  structure.  The  system  also 
enables  constraints  and  Inferences,  as  well  as  actions,  to 
be  represented  as  procedure*,  which  can  be  used  In  both  a 
goa 1 -dl rected  and  applicative  manner.  A  detailed  example 
Illustrates  these  capabl  1 1  tl  es. 
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ABSTRACT 


An  automatic  programming  system  is  distinguished  from  a  conventional  programming 
system  by  its  use  of  an  explicit  semantic  model  of  the  application  domain  to  structure 
the  dialogue  between  the  system  and  the  user,  to  understand  the  user's  responses,  and 
to  translate  these  Into  actions.  The  major  differences  between  the  design  effort 
i  reported  here  (and  the  project's  main  focuses)  and  other  automatic  programming  projects 
are*  first,  its  independence  of  any  particular  domain  and  Its  dl aiogue-driven 
acquisition  of  the  domain  to  produce  a  Loose  Mode  it  second,  the  Informal  and  typically 
1  1 1 -structured  manner  In  which  both  this  Loose  Model  and  the  task  to  be  programmed  are 
specified  and  their  translation  into  a  directly  I nterpretabie  Precise  Model. 

Throughout  the  system,  knowledge  is  represented  by  tuples,  and  structured  by*  a 
theory  of  domains  and  their  model  I  nterreiat I onshl pst  a  strong  notion  of  types;  and  the 
use  of  constraints  on  all  arguments  of  the  tuples.  Use  of  compound  expressions, 
enabling  the  Intermixing  of  patterns  to  be  Instantiated  with  expressions  to  be 
evaluated,  greatly  simplifies  program  control  structure.  The  system  also  enables 
constraints  and  Inferences,  as  well  as  actions,  to  be  represented  as  procedures,  which 
can  be  used  In  both  a  goal-directed  and  applicative  manner.  A  detailed  example 
illustrates  these  capabilities. 

The  research,  sponsored  by  ARPA  under  Contract  No.  DAHC15  72  C  0308,  ARPA  Order 
No.  2223/1,  Program  Code  No.  3030  and  3P10,  is  directed  toward  vast  Improvement  In 
both  efficiency  and  quality  of  the  production  of  software.  The  work  Is  of  particular 
Importance  to  the  large  very  diverse  application  software  packages  being  developed  by 
all  branches  of  the  Military. 
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INTRODUCTION 


The  work  reported  here  represents  the  first  phase  of  the  automatic  programming 
project  at  the  USC/ Information  Sciences  Institute  (ISI).  After  an  Initial  survey  of 
current  work  In  the  field,  the  group  developed  a  plan  for  attacking  what  appeared  to  be 
tiie  fundamental  Issues.  This  took  the  form  of  an  actual  system,  the  design  and 
Implementation  of  which  Is  now  In  Its  early  stages.  Rather  than  enter  Into  a  detailed 
discussion  of  what  we  understand  automatic  programming  to  be.  It  will  emerge  from  the 
discussion  of  the  system  being  built.  The  results  of  the  Initial  survey  and  the 
overall  view  of  the  field  adopted  are  reported  e I sewherel 1 , 2] .  One  point  of  that  view 
should  be  stressed  here.  This  project  Is  not  seen  as  an  Incremental  advance  In 
computer  languages  or  the  art  of  programming,  but  rather  as  an  attempt  to  make  the 
power  of  the  computer  available  to  a  large  class  of  users  without  the  necessity  of  a 
step  similar  to  the  one  now  called  programming.  Ultimately,  a  client  should  be  able  to 
negotiate  directly  with  a  computer  system  In  much  the  same  terms  as  he  now  negotiates 
with  a  programmer. 

Computer  usage  generally  falls  Into  two  categories^  use  of  existing  programs  or 
creation  of  new  ones.  There  Is  no  sharp  distinction  between  the  two  because  data  fed 
Into  existing  programs  can  be  thought  of  as  Instructions  which  program  their  behavior, 
and  because  the  creation  of  new  programs  utilizes  either  compilers  or  Interpreters 
which  treat  such  instructions  as  data.  Also,  the  techniques  for  translating  a  task 
into  appropriate  input  for  the  two  are  very  similar.  Nevertheless,  we  have  chosen  to 
deal  only  with  programming  activities,  which  we  regard  as  the  process  of  translating  a 
task  to  be  performed  into  a  computer  language,  taking  Into  account  the  constraints  and 
limitations  of  both  the  computer  and  the  domain  of  interest  from  which  the  task  was 
drawn. 


The  constraints  and  restrictions  of  the  computer  have  Increasingly  been 
incorporated  and  internalized  In  programming  advances  for  several  years.  They  are 
manifest  In  better  languages,  automatic  storage  mechanisms,  and  optimizations  of  many 
forms. 
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On  the  other  hand,  the  structure,  constraints,  and  limitations  of  the  problem 
domain  have  generally  not  been  Incorporated  into  programming  systems.  The  utilization 
of  such  knowledge  is  a  major  theme  of  automatic  programming  that  characterizes  the 
distinction  between  It  and  conventional  programm! ng,  and  raises  a  number  of  issues.  If 
the  system  Is  to  understand  something  of  a  domain  —  a  particular  universe  of  discourse 
how  is  the  knowledge  on  which  this  understanding  is  based  to  be  represented?  What 
procedures  can  be  made  aval iabie  for  exploiting  this  knowledge  In  guiding  the  system's 
interaction  with  a  user  and  In  generating  programs?  How,  in  particular.  Is  the 
essentially  nonprocedural  Information  in  constraints  and  limitations  to  be  reflected  in 
a  procedural  form?  What  can  be  done  to  help  Identify  inconsistencies?  How  can  the  system 
be  given  a  capacity  for  Inference  simliai  to  the  one  that  forms  the  mainstay  of  human 
communication  aud  which  allows  obvious  details  to  be  left  unspecified?  Will  the  system 
be  able  to  understand  its  own  products  well  enough  to  be  able  to  modify  them  in  response 
to  changed  requirements?  Answers  to  these  questions  define  the  front  on  which  important 
advances  In  automatic  programming  will  be  made. 

Hitherto,  the  designers  of  programming  systems  have  concentrated  their  attention 
on  creating  an  Instrument  that  would  be  easy  to  play.  Like  ail  instruments,  the  system 
had  a  purely  passive  role  In  the  programming  enterprise.  We,  on  the  other  hand,  took 
the  view  that  the  problem  of  programming  is  largely  a  problem  of  communication  and  that 
communication,  to  be  easy  and  natural,  must  be  with  an  active  agent. 

Thus  the  main  distinction  between  conventional  and  automatic  programming  Is  the 
latter's  use  of  a  semantic  model  of  a  domain  to  structure  the  dialogue  between  the 
system  and  the  user,  to  understand  the  user's  responses,  and  to  translate  the  user's 
responses  Into  actions*  The  major  distinctions  between  the  work  reported  here  and 
other  automatic  programming  efforts  are1  first,  its  independence  of  any  particular 
domain  and  Its  acquisition  of  the  domain  model  through  a  dialogue  with  the  user; 
second,  the  Informal  and  typically  I i l-strud tured  manner  in  which  both  the  domain 
semantics  and  the  task  to  be  programmed  are  specified.  In  fact,  these  two  areas 
represent  the  two  main  focuses  of  the  project*  dialogue-driven  acquisition  of  a  domain 
and  translation  of  I  ll-deflned  specifications  into  a  precise  form. 
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OVERALL  SYSTEM  STRUCTURE 


In  our  plan,  the  automatic  programming  system  consists  >f  four  processing  modules 
and  six  data  bases.  The  data  bases  consist,  as  much  as  possible,  of  descriptive 
(rather  than  imperative)  knowledge,  organized  so  that  the  system  can  use  this  knowledge 
in  many  different  ways.  These  data  bases  have  been  segregated  because  of  the  different 

logical  functions  they  perform  and  because  of  the  way  they  are  treated  by  the  different 

processing  modules. 

Data  Bases 

The  Oomal n  Knowledge  data  base  contains  ail  the  descriptive  information  about  the 
problem  domain,  such  as  the  types  of  objects  which  can  exist  In  the  domain  and  their 

descriptions,  the  types  of  actions  which  can  occur  in  the  domain,  the  relations  which 

may  exist  between  objects  or  events  (action  occurrences),  and  any  constraints  which 
must  be  satisfied  by  the  domain. 

The  Domain  Model  contains,  at  any  point  in  time,  an  instantaneous  snapshot  of  the 
instantiated  objects  in  the  domain  and  their  relationship  with  other  objects  in  the 
domain.  It  represents,  through  time,  a  direct  simulation  of  the  problem  domain. 

The  Loose  Model  contains  the  problem  statement  In  an  Imprecise  form  which  may  be 
incomplete  or  ambiguous  and  which  can  only  be  understood  in  the  context  of  the 
information  In  the  Domain  Knowledge  and  Oomal n  Model  data  bases. 

The  Precise  Model,  on  the  other  hand,  represents  a  precise,  complete,  unambiguous, 
and  directly  interpretable  process  for  solving  the  posed  problem. 

The  Strategy  Knowledge  data  base  consists  of  Information  which  guides  the  choice 
of  actions  and/or  objects  for  those  actions  when  alternative  possibilities  exist  within 
the  domal n. 
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finally,  the  Script  data  base  contal  ns  partially  filled  in  forms  which  guide  the 
dialogue  between  the  system  and  the  user  and  are  dynamically  altered  on  the  basis  of 
the  user's  input  and  by  the  demands  of  the  Model  Completion  module. 

Processl ng  Modu les 

Initially,  to  simplify  the  Implementation,  the  processing  modules  wi  II  be  highly 
self-contained  and  have  only  a  limited  knowledge  of  the  processing  and  requirements  of 
other  modules.  Later  these  modules  will  be  more  highly  integrated  and  cooperative. 

The  Oomal  n  Acquisition  module  is  responsible  for  all  communications  with  the  user, 
with  building  the  Domain  Knowledge  and  Domain  Model  data  bases,  with  obtaining  the 
Loose  Model  statement,  with  determining  on  syntactic  grounds  the  well-formedness  of  all 
this  Information,  with  building  and  modifying  the  Script,  and  with  using  it  to  direct 
the  dialogue  for  the  acquisition  of  further  information  necessary  for  such  syntactic 
well-formedness  or  requested  by  the  Model  Completion  module. 

The  Model  Completion  module  takes  the  Loose  Model  and  determines  Its  semantic 
well-formedness  on  the  basis  of  the  information  In  the  Domain  Knowledge  and  Domain 
Model  data  bases.  It  Is  responsible  for  transforming  the  Loose  Model  Into  an 
operational  1  nterpretabie  form  called  the  Precise  Model.  Any  inability  to  perform  this 
transformation  results  in  a  description  of  the  cause  being  passed  back  through  the 
Script  to  the  Domain  Acquisition  phase  which  then  interacts  with  the  user  to  correct 
the  deficiency  (usually  by  adding  more  knowledge  about  the  domain  to  the  Domain 
Knowledge  data  base). 

The  Interpreter  executes  the  action  sequences  In  the  Precise  Model  and  updates  the 
Domain  Model  accordingly.  It  Is  responsible  for  locatinq  objects  defined 
descriptively,  for  evaluating  conditions  to  select  alternative  sequences  of  actions, 
and  for  maintaining  restrictions  on  domain  behavior. 

The  Data  Base  Handler  is  responsible  for  maintaining  the  various  data  bases, 
deciding  on  store-recompute  policy,  maintaining  consistency,  and  (through  inference) 
obscuring  the  difference  between  explicit  and  Implicit  data. 
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A  primary  objective  of  our  project  has  been  the  creation  of  a  core  experimental 
system  for  testing  progress  on  Domain  Acquisition  and  Model  Completion.  As  such,  the 
Interpreter  and  Data  8ase  Handler  have  been  completely  specified,  and  will  be  used  for 
both  the  Precise  Mcdei  and  the  Implementation  of  the  automatic  programming  system 
Itself.  To  fully  uti  !  1  ze  these  Implementation  capabl 1 1 tl es,  the  Domal n  Acquisition  and 
Model  Completion  modules  will  be  treated  as  domains  with  their  own  actions,  objects, 
constraints,  and  rules  of  Infr.ence.  This  bootstrapping  will  focus  attention  on  the 
real  problems  of  using  our  a,oroach  In  complex  domains. 

A  more  detailed  description  of  the  system  Is  given  In  the  following  sections  by 
focusing  on  the  major  components*  the  representat 1  on  of  knowledge,  the  transformatl on 
performed  by  the  Domain  Acquisition  and  Model  Completion  modules,  and  the  form  of  the 
Precise  Model  produce  by  Model  Completion.  This  description  Is  followed  by  an 
annotated  .xample. 

KNOWLEDGE  REPRESENTAT  ION 

Throughout  the  system,  knowledge  Is  represented  as  stored  tuples.  The  first 
element  of  any  tuple  specifies  the  type  of  tuple  and  the  rest  of  the  elements  are  the 
arguments  for  that  tuple.  Each  stored  tuple  Is  associated  with  a  particular  domain. 
Data  bases  are  compartmentalized  Into  separate  domains  which  form  a  lattice.  Each 
domain  Is  defined  as  A-KIND-OF  (AKO)  another  domain  and  this  structure  forms  the  basis 
of  the  domain  lattice.  The  Interpretation  of  the  lattice  structure  Is  that,  unless 
specifically  prohibited,  properties  (of  all  types)  from  higher  level  domains  are 
Inherited  by  lower  level  ones. 

The  structure  of  knowledge  In  the  system  Is  highly  constrained  by  two  mechanisms* 
types  and  constraints.  Each  element  of  a  tuple  must  be  of  a  type  acceptable  for  that 
argument  as  specified  In  the  definition  of  that  kind  of  tuple.  Like  domains,  types  are 
defined  by  A-KINO-OF  relation  and  form  lattices.  (This  structure  Is  very  similar  to 
NAPLf3J«)  element  of  a  tuple  Is  acceptable  I  f  1  ts  type  Is  the  same  as  that  specified 
In  the  tuple  definition,  or  If  Its  type  Is  a  lattice  descendant  of  the  specified  type. 
In  addition  to  type  acceptability,  the  elements  of  a  tuple  must  also  sati sfy  arbitrary 
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constraints  specified  In  the  topi e  def  i  ni  U on.  These  constraints  are  checked  at  the 
time  that  the  tuple  is  added  to  a  domain. 

domain  consist"  of  types  (objects),  actions,  relations,  constraints,  raids  ol 
Inference,  and  Instantiations  of  all  of  the  above.  looether  vltn  the  type  and 
constraint  mechanisms  for  topics,  this  kno.ledoe  of  the  kinds  of  Information  contained 
Vltnin  a  domain  represen.s  the  syntactic  basis  osed  by  the  Domain  Acooisition  modole  to 
construct  and  modify  its  Script,  and  hence  its  dialogue  with  the  user. 


The  following  tuples  are  used  to  structure  knowiedoe  in  the  system: 


(AKO  x  y  z 

If  present  i  r.  a  Fur 
Foilowinq  z  can  be  opti 
con  I st I nq  r  f  proper t 
and  also  be  known),  or 
satisfies  by  Instance 
the  system.  OBJECTS, 
ATTRIBUTES  can  all  be 
an  instantiation  of  a  I 


*  **  a  ^ A-KIND-OF)  of  y.  t  Is  optional  and 

ther  Spec! fl  cat i on  of  y  which  ensures  it  Is  also  an  x. 
onal  arguments  which  specify  a  case  frame  for  x 

rlLn AYf  t''US7  <mUSt  e)“'sU»  REOUIREO  (.rust  exist 
CAM.OT  be  present,  and  CONSTRAINTS  which  must  be 

S  *mmc‘  r?  specified  as  an  AKO  is  a  TYPE  in 

ACTIONS,  CONSTRAINTS,  INFERENCES,  DOMAINS,  and 
specified  by  AXE.  In  an  AKO,  y  may  be  either  a  TYPE  or 


:i!*  ?d”°n  <«rlt.l-,tat«  .  married))) 

L.  _  I  Th!  (*}  in  the  above  further  Specifications  refer  to  the  entity 

~  *  *"•  -  ■  — 

tl  y*  ym)  *  ,s  a  RELATION  or  ACTION  with  y  z  ...  as  arquments 

SST2  ACTION  Jup?e)ln  "  Pr°t0t^  descr Iptior^of  I"??;  the  A-REL  A?  I  ON-ON 

V  2  (AR°  X  LLriTl  iC0“ST*A!NIS  a  b  ••• »  --  X  is  the  name  of  ARO  arguments 

y  2  •••  specified  by  their  name  and  allowed  TYPE.  The  last  element  of  th. 

tuple  may  be  a  sel  of  CONSTRAINTS  which  must  be  satisfied  by  In  I  nstandltfJn 

wberlhr  An?  °f  the  ar9um«nts  «n  be  named  by  specifying  a  pal  r  (r  s) 

i'nnlit  Jj  *  ^  °Sed  t0  ,de"tIfy  *  particular  argument  and  to  help  the 

P  system  correctly  position  the  arguments)  and  s  is  the  TYPE. 

(ACTION  x  y  z  ...  r)  -  x  is  the  name  of  an  ACTION.  v  z  are  th» 

^r^rfbuterof^he^T^N^such6  SSlSSiSi^V  £°  TathU  '  Jy*  ^ 

POSTCONDI  T iCNS^whl ch  Jan^be  ' a^ed^af °'  ^ 
PRECONDITIONS  necessary  before  It  Is  st^rtldj  etc.  °  comPJeted* 

ASSERTED  x*ic  2\*  .  y  ?S  f  pattern  can  be  instantiated  then  z  can  be 
ASSERTEO.  x  is  a  list  of  variables  to  be  bound  in  the  patterns. 

be  r  J  "a  yrls  a  pattern’  or  tbe  negation  of  one,  which  must 

(but  not  during  those  ACTIONS ^and^t  £CJI0N  defined  In  the  associated  DOMAIN 
in  aSht  iow^lJ  S’  and  not  be  ore  and  after  more  primitive  ACTIONS 
pattern.  1  x  Is  a  list  of  variables  to  be  bound  Jn  the 


DOMAIN  ACQUISITION 


The  Domain  Acquisition  module  has  responsibility  for  communicating  with  the  user 
In  natural  language  and  extracting  from  the  dialogue  the  Information  needed  to  build 
the  Domain  Knowledge,  Domain  Model,  and  Loose  Model  data  bases.  The  mechanism  for 
guiding  this  dialogue  Is  the  Script.  The  basic  Idea  Is  to  use  the  regularities  and 
restrictions  In  a  domain  to  structure  new  knowledge  about  that  domain  and  Indicate 
where  more  Information  Is  required.  Thus,  each  of  the  entitles  of  a  domain  can  be 
thought  of  In  terms  of  an  extended  Case  GrammarI4],  which  specifies  a  “frame“  or  *orm 
to  be  filled  In  for  that  entity.  As  with  all  forms.  It  has  certain  fields  which  must 
have  specified  types  of  Information,  others  which  may  be  present,  absent,  or  present  In 
varying  amounts.  It  may  also  specify  certain  well-formedness  criteria  of  a  more  global 
nature  for  entitles  of  this  type.  The  form  represents  a  template  which  Is  to  be 
Instantiated  In  a  domain. 

These  Instantiated  forms  may  be  either  fully  or  partially  Instantiated.  Fully 
Instantiated  ones  represent  constants  In  the  domain.  Partially  Instantiated  forms  can 
be  used  both  In  building  up  the  intrarelated  structure  of  one  of  the  data  bases  or  as  a 
form  for  further  Instantiation.  In  particular,  such  partially  Instantiated  forms  can 
be  used  In  the  Script  as  a  guiding  mechanism  for  the  dialogue.  In  addition,  some  forms 
represent  refinements  of  others  which  either  fill  In  certain  fields  of  that  forr,  or 
expand  It  by  adding  new  fields  which  may  or  may  not  be  filled  In.  Thus,  forms  can 
create  either  Instantiated  entitles  In  a  domain  or  further  forms. 

Such  a  structure  suggests  the  development  of  a  language  for  the  description  of 
forms  and  how  they  should  be  fl  lied  In.  Domain  Acquisition  would  then  become  a 
table-driven  module  which  from  Its  knowledge  of  communication  (and  natural  language) 
and  the  particular  form  given  It  to  fl 11  In  would  engage  In  a  dialogue  with  the  user  to 
obtain  the  necessary  Information.  This  view  strengthens  the  conception  of  Domain 
Acquisition  as  the  “syntactic*  component,  as  It  would  not  know  what  the  fields  In  the 
form  were,  or  how  they  were  to  be  used,  but  only  their  syntactic  construction  and 
relationship  to  other  fields  In  the  form. 
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This  conception  has  the  advantage  of  focusing  attention  on  how  such  a  form  could 
be  used  to  direct  the  dialogue  and  would  greatly  simplify  any  changes  In  those  forms 
necessitated  by  further  understanding  cf  Model  Completion  processing.  It  would  also 
open  the  door  for  other  Loose  Models  which  might  not  be  procedural ly  oriented.  The 
problem  with  utilizing  this  technique  is  finding  some  way  to  capitalize  on  the 
regularity  In  a  domain  without  imposing  an  undue  rigidity  on  the  dialogue  or  the  forms 
of  Information  accepted. 

One  technique  being  utilized  to  study  the  structuring  and  extraction  of 
Information  from  a  dialogue  Is  the  analysis  of  dialogues  In  which  the  content  words  of 
a  domain  have  been  systematically  replace*  by  nonsense  vords[5].  In  these  dialogues, 
one  member  of  the  group  plays  the  role  of  the  system  while  another  plays  that  of  a 
user.  The  analysis  of  these  dialogues  illustrates  the  difficulties  encountered  by  an 
automatic  programming  system  acquiring  Information  In  a  new  domain  and  Is  beginning  to 
yield  a  se:  of  applicable  rules  and  techniques. 

There  are  three  components  to  the  Oomaln  Acquisition  phase:  a  linguistic  front  end 
which  translates  natural  language  Input  Into  Internal  form;  a  dialectic  component  which 
utilizes  the  Script  to  guide  the  dialogue  with  the  user;  and  a  structure  extraction  and 
building  component  which  uses  tuple  restrictions  on  element  type  and  constraints  to 
select  the  intended  meaning  of  an  Input,  spot  inconsistencies,  and  determine  the  need 
for  missing  Information.  Work  Is  centering  on  these  last  two  components,  leaving  the 
linguistic  front  end  for  the  future. 


The  Loose  Model  represents  an  Informal  statement  of  a  problem  In  a  domain  which 
can  be  processed  with  the  aid  of  information  contained  In  the  Domain  Model  and  Domain 
Knowledge  data  bases  with  the  application  of  Intelligence.  Thus,  with  the  right  kind 
of  data  base  access  and  processor,  the  Loose  Model  is  Interpretable.  The  main  function 
of  Model  Completion  Is  to  reduce  the  intelligence  requirements  on  the  run-time 
processor  and  to  limit  the  access  during  run-time  to  the  Domain  Knowledge  data  base. 
This  distinction,  though  not  sharp,  lies  at  the  very  heart  of  programming.  A  program 


embodies  an  algorithm  and  It  Is  the  essence  of  an  algorithm  that  It  does  not  KNOW  what 
It  Is  doing.  In  oth-*r  words.  It  requires  understanding  of  the  problem  domain  to  write 
a  program,  but  the  eventual  program  operates  blindly.  If  a  process  must  have  recourse 
to  an  understand! ng  of  a  domain  to  continue  with  the  solution  of  a  task,  then  It  does 
not  embody  a  method  for  solving  that  problem,  and  Is  therefore  not  a  program.  It  Is, 
Instead,  a  problem  solver  which  develops  solutions  essentially  by  (heuristic)  trial  and 
error.  In  programs,  the  need  for  such  recourse  has  been  anticipated  and  incorporated 
Into  the  steps  of  the  algorithm  so  that  the  structure  of  the  domain  and  problem  solving 
are  no  longer  required  during  execution. 

Such  anticipation  and  removal  of  reliance  on  Domain  Knowledge  and  problem  solving 
can  be  regarded  as  a  compiling  process  and  is  the  main  function  of  Model  Completion. 
Closely  related  Is  the  issue  of  efficiency  which  represents  good  ways  of  removing  such 
dependencies.  Our  focus  will  be  to  produce  running  programs,  not  optimized  ones. 
Hence,  the  concern  Is  more  with  widening  the  range  of  transformations  which  can  be 
performed  on  Loose  Models  and  the  freedoms  thus  allowed  In  the  Loose  Model 
specification  than  In  eliminating  redundant  checks  or  optimally  ordering  the  processing 
in  the  produced  programs. 

Thus  Model  Completion  Is  the  translator  from  the  Loose  to  Precise  Model.  As  such. 
Its  main  responsibility  is  to  transform  actions  Into  procedures.  This  Involves  filling 
In  procedure  invocations  (fully  instantiating  the  argument  lists)  and  making  these 
consistent  with  the  procedure  requirements!  filling  In  missing  links  (making  explicit 
the  access  path  to  required  data)!  deciding  explicitly  when  to  perform  bindings  and 
evaluations  in  the  Domain  Model!  deciding  explicitly  how  to  handle  possible  errors! 
identifying  missing  information  and  removing  dependence  on  It  until  (and  If)  It  Is  used 
during  execution!  and  performing  back  translations  from  Precise  to  Loose,  both  for 
describing  execution  behavior  and  for  explaining  why  actions  were  selected.  The 
annotated  example  following  the  Precise  Model  section  illustrates  the  kinds  of 
transformat  ions  planned  for  Model  Completion. 

One  transformation  particularly  worth  noting  Is  the  multiple  use  of  actions  in 
both  the  applicative  and  goal-directed  forms.  In  Precise  Model  form,  actions  have  a 
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set  of  parameters  and  local  pattern  match  variables.  It  Is  assumed,  upon  entry  to  such 
an  action,  that  the  parameters  have  been  bound  and  that  the  1  oca  1  va, 1 abl es  are 
unboun,.  In  a  goal-directed  Invocation,  as  part  of  an  ACHIEVE  statement,  an  action  Is 
being  Invoked.  It  Is  Invoked  because  Its  result  matches  a  needed,  but  as  yet 
unfulfilled,  part  of  the  form  to  be  achieved.  Since  this  occurs  in  the  midst  of  a 
pattern-match,  the  form  is  partially  Instantiated  and  only  some  of  the  arguments  needed 
for  the  action  may  have  been  determined  already.  Two  possibilities  for  processing 
exist.  The  first  is  for  the  system  to  preselect  possible  values  for  the  undetermined 

parameters,  invoke  the  action,  and  if  It  fails  try  another  set  of  values,  and  so  on. 

The  second  possibility  is  that  the  action  Is  modified  (logically)  so  that  the 
undetermined  parameters  are  treated  as  local  variables  to  be  bound  by  the  pattern 
matches  within  the  action  rather  than  by  being  determined  from  the  outside.  They, 
however,  remain  bound  when  the  action  is  exited.  Thus,  conceptually,  the  undetermined 

arguments  are  bound  by  performing  the  action.  This  second  possibility  is  much  more 

reasonable,  allowing  the  inherent  constraints  of  the  action  to  guide  the  bindings  of 
the  unbound  arguments,  and  occurs  automatically  In  the  Precise  Model.  By  definition, 
the  pattern  matcher  Instantiates  all  unbound  variables  encountered  in  a  pattern  and 
leaves  unchanged  those  already  bound.  Hence  any  parameters  which  have  a  prespecified 
value  upon  entry  to  the  routine  will  have  that  value  unchanged,  while  those  that  are 
unbound  will  have  an  instantiated  value  assigned  in  the  normal  course  of  execution  of 
the  action.  The  binding  mechanism  In  the  Precise  Model  causes  these  Instantiated 
values  to  automatically  be  reflected  In  the  arguments  of  the  Invocation.  A  related 
Issue  Is  the  possible  bindings  In  the  pattern-directed  Invocation  of  variables  local  to 
the  Invoked  action.  Unfortunately,  such  bindings  are  not  automatically  reflected  In 
the  Invoked  action  and  a  special  type  of  entry  must  be  performed  when  such  conditions 

arise. 


The  Precise  Model  Is  the  restatement  of  the  user's  problem  In  the  programming 

language  AP/1 £6].  Ibis  language  Is  an  extension  of  L1SP[7],  which  supports  associative 
relational  data  bases  with  the  domain  ccmpar tmenta 1 1 zat I  on  described  earlier,  strongly 
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typed  varl-ables,  compound  pattern  Hatches,  and  failure  control.  Strong  typing  and 
compound  patterns  are  especially  Important  In  simplifying  the  system's  writing  of  the 
Precise  Model  by  minimizing  the  translation  between  It  and  che  Loose  Model  and  by 
reducing  and  simplifying  the  control  structures  required.  In  fact,  compound  patterns 
have  enabled  backtrack) ng  to  be  completely  eliminated  and  replaced  by  a  single  FOR  loop 
which  iterates  through  a  set  of  Instantiations  of  the  compound  pattern.  It  also 
enables  Intelligence  to  be  applied,  within  the  pattern  matches,  to  determine  how  best 
to  obtain  valid  I  ns t ant  fat  I  ons. 

Additionally,  Model  Completion  utilizes  only  a  subset  of  AP/I  (which  Is  also  the 
Implementation  iangua?*  for  the  project)  to  further  simplify  the  writing  and  analysis 
of  Precise  Model  programs.  The  major  difference  Is  that  the  Precise  Model  utilizes  no 
free  or  local  variables  except  for  pattern  match  variables  which  are  Instantiated 
during  the  matching  process.  All  communication  between  routines  Is  either  via  explicit 
parameter  passing  or  through  data  contained  in  the  Domain  Model. 

AP/1  generally  allows  the  arbitrary  mixing  of  tuples  to  be  Instantiated  nd 

functions  to  be  evaluated.  This  Includes  the  functions  AND,  OR,  and  NOT,  as  well  as 
any  other  defined  LISP  functions.  It  Is  assumed  that  such  functions  have  no  side 

effects.  Each  tuple  In  an  expression  Is  treated  as  a  function  and  evaluated  If  It  has 
a  function  definition.  If  not,  then  It  is  treated  as  a  pattern  to  be  Instantiated. 
Because  there  are  no  free  variables,  and  the  only  local  variables  are  pattern  match 
variables,  the  rule  for  Instantiation  Is  very  simple.  Any  parameter  or  variable  which 
Is  unbound  at  the  time  It  Is  encountered  within  a  pattern  Is  I nstantl  ated.  Already 
bound  variables  are  left  unchanged. 

The  value  of  a  pattern  is  always  the  Instantiated  version  of  that  pattern  If  the 
match  was  successful  or  NIL  otherwise.  No  other  possibilities  exist.  Thus  all  pattern 
matches  return  either  the  instantiated  pattern  or  NIL  and  the  concept  of  failure  does 

not  exist  within  the  pattern  matcher.  It  always  returns  to  Its  caller  with  one  of 

these  values. 

The  routines  (statements)  which  invoke  the  pattern  matcher  may  take  other  actions 
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with  the  returned  value.  They  may  street  from  It  particular  bindings  or 
subexpressions  or  cause  failure  when  a  NIL  value  Is  returned.  Each  of  the  “statements* 
In  AP/1  is.  In  fact,  a  function  which  uses  the  value  returned  from  the  pattern  matcher 
as  It  sees  fit.  In  this  regard,  the  AND,  OR,  and  NOT  functicns  are  no  different  than 
any  other  in  the  system. 

One  such  useful  function  Is  Further  Specification.  It  takes  a  typed  variable  and 
a  pattern  to  be  Instantiated  as  its  arguments.  If  the  pattern  is  successfully 
Instantiated,  the  value  of  the  typed  variable  Is  returned  as  the  value  of  the  function 
and  NIL  Is  returned  otherwise.  Thus  Further  Specification  can  be  viewed  as  "fird  the  x 
such  that  <pattern>“. 

In  AP/I  the  ATTEMPT  statement  Is  used  to  deal  with  ail  failures  which  occur  in  the 
attempted  statement.  The  ATTEMPT  statement  also  automatically  creates  a  new  context 
for  the  execution  of  the  attempted  statement.  If  the  statement  Is  successful,  then  the 
tuples  In  the  context  (which  can  be  thought  of  as  a  temporary  domain)  are  promoted  to 
the  context  existing  before  the  attempt.  If  not,  ail  these  tuples  are  removed  from  the 
system.  Thus  the  sld  effects  of  failures  are  automat  I ca I ly  removed  from  the  system. 

Any  statement  which  can  fall  can  have  THEN  and  ELSE  clauses  attached  to  it.  This 
Includes  the  IS,  ATTEMPT,  ACHIEVE,  ASSERT,  REMOVE,  FOR,  and  PERFORM  statements.  In 
each  case.  If  the  statement  completes  successfully,  then  the  THEN  clause.  If  present. 
Is  executed.  Failure  of  the  statement  causes  the  execution  of  the  ELSE  clause  which. 
If  present,  prevents  further  promulgation  of  the  failure.  The  one  exception  to  this  is 
the  ATTEMPT  statement  which  handles  failure  whether  or  not  an  ELSE  clause  Is  present. 

The  FOR  statements  are  used  to  loop  through  a  set  of  I nstanti atl  ons  of  a  pattern, 
either  performing  some  operation  on  them,  or  searching  for  a  single  one  which  satisfies 
some  criteria.  The  suspension  and  continuation  of  I nstant I  at  I  ons  afforded  by  r0R 
statements  is  the  only  mechanism,  outside  the  pattern  matcher,  for  attempting  a 
sequence  of  instantiations  looking  for  a  successful  one.  In  this  regard  it  Is  very 
CONNIVER-i I ke[8],  but  it  Is  only  effective  within  the  loop.  There  Is  no  exit-  and 
reentry-type  capability.  The  pattern  matcher  has  Internal  backtracking  mechanisms  for 
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searching  for  successful  Instantiations  of  patterns.  The  compound  pattern  matches  are 
la-gely  responsible  for  eliminating  the  need  for  backtracking  In  the  language  outside 
of  the  pattern  matcher. 

The  IS  statement  Is  used  to  retrieve  Information  from  a  data  base  by  Instantiating 
a  pattern.  If  the  Instantiation  falls,  tfien,  unless  explicitly  prohibited,  the 
instantiation  Is  attempted  again  using  the  rules  of  inference  specified  or  any  rules  of 
Inference  available  in  the  context  and  domains  searched. 

The  ACHIEVE  statement  is  similar  except  that  If  both  the  search  and  inference  are 
Insufficient  to  Instantiate  the  pattern,  then  the  action  specified,  or  any  aval  lable 
actions,  are  used  to  try  to  achieve  an  instantiated  pattern. 

The  ASSERT  and  REMOVE  statements  are  used  to  add  and  delete  tuples  from  a  context 
or  domain.  In  each  case,  unless  specifically  prohibited,  the  consistency  of  the  data 
base  Is  checked  after  the  statement  Is  executed.  If  an  inconsistency  Is  found,  then 
the  statement  falls  and  the  changes  are  undone. 

The  PERFORM  statement  behaves  exactly  like  the  IS  statement  except  that  If  the 
pattern  Is  I nstant I ated.  It  Is  then  evaluated.  Finally,  the  FAIL  statement  Is  used  to 
explicitly  Invoke  the  fall  mechanisms  described  earlier. 

EXAMPLE 

The  fol loving  annotated  example  of  the  system's  planned  behavior  was  derived  from 
one  In  the  QLISP  Manuai[9].  The  original  problem  statement  Is* 

To  make  people  happy  either  find  a  compatible  marriage  or  make  them  rich.  A 

marriage  Is  compatible  If  both  people  are  unmarried,  of  opposite  sex,  have  a 

hobby  In  common  and  the  vl  fe  Is  not  more  than  five  years  older  than  the  man. 

Someone  is  rich  If  their  net  vorth  Is  over  a  mi  I  lion  dollars. 

After  er.gajping  In  a  dialogue  vl  th  the  user  (suppressed  here),  the  system  vouid 
arrive  at  the  Loose  Mode)  stage  In  vhlch  the  following  Informal  description  of  the 
problem  and  domain  exists* 
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1. 

2. 

3- 

4. 

5. 

6. 
7- 
8. 
9. 

10. 

11. 

12. 


(AKC  PERSON 

(ARQ  sex 

(ARO  MARITAL-STATUS 

(ARO  EMOTION  PERSON 

(ARO  NETWORTH  PERSON 

(ARO  WEALTH  PERSON 

(ARO  HOBBIES  PERSON 

(AKO  BEU  Y-DANCINC 

(AKO  GARDENING 

(AKO  PROGRAMMING 

(ARO  AGE  PERSON 

(ACT  I  Of  MARRY 

(CONTRCLLED-BY 
(PRECGNDI  T  IONS 


13. 

14. 

15. 

16. 

17. 

18. 
19. 


20. 

21. 


(DESCRIPTION 

(POSTCONDITIONS 

(CONSTRAINT 


(CONSTRAINT 


OBJECT) 

PERSON  (GNE-OF  MALE  FEMALE)) 

PERSON  (CNE- OF  MARRIED  UNMARRIED)) 
(ONE-OF  HAPPY  SAD  BLAH)) 

NUMBER) 

(ONE-OF  RICH  MIDDLE  PGGRj) 

(SET  ACTIVITY)) 

ACTIVITY) 

ACTIVITY) 

ACTIVITY) 

.  _  NUMBER) 

(PARAMETERS  PERSON  PERSONS  1 ) 

SYSTEM) 

(AND  (UNMARRIED  PERSONS!) 

(UNMARRIED  PERSON) 

(NEQ  (SEX  PERSONS! ) 

(SEX  PERSON)))) 

(ASSERT  (MARRIED  PERSONS!  PERSON))) 
(MARRIED  PERSONS!  PERSON))) 


(PERSONS  l 
(MARRIED 
(MARRIED 


PERS0NS2 
PERSONS! 
PERSONS  1 


PERS0NS3) 
PERS0NS2 ) 
PERS0NS3 ) ) 


(IMPLIES  (PERSON) 


(AKO 

(AKO 

(ACTION 


(AKO 

(AKO 


WIFE 
HUSBAND 
MAKEHAPPY 


(PERSON)  (MARRIED  PERSON  PERSON)) 
(IMPLIES  (PERSONS!  PERS0NS2 )  (MARRIED  PERSONSl  PERS0NS2 ) 

(MARRIED  PERS0NS2  PERS0NS1)) 

(GT  (NETWORTH  PERSON)  1000000) 

(PERSON  RICH)) 

PERSON  FEMALE  MARRIED) 

PERSON  MALE  MARRIED) 

(PARAMETERS  PERSON) 

(CONTROLLEO-BY  USER) 

(DESCRIPTION  MAKEHAPPY  (IF  (OR  (PERSON  RICH) 

(HAS  PERSON  COMPATIBLE-MARRIAGE)) 
(ASSERT  (PERSON  HAPPY))))) 
MARRIAGE  EVENT  MARRY ) 

(COM.  ATIBLE-MAPRIAGE)  MARRIAGE 

(LT  (AGE  WIFE)  (AGE  HUSBAND+5 ) ) 

(EXISTS  (HGBBYS1 )  (AND 

(HOBBY  HUSBAND  HGBBYSl) 

I  HORRY  WIFE  HOBBYS  1  )  )  ) ) 


The  impression  to  be  gained  from  the  Loose  Mode!  stage  Is  that  the  Informal 
description  Is  closely  related  to  the  natural  language  input  given  the  system.  The 
major  problems  of  understanding  this  representation  and  transforming  It  Into  an 
operational  program  are  left  for  the  loose  to  precise  translation. 


Some  of  the  Items  above  are  Imprecise  and  are  modified  as  part  of  model 
completion.  For  example.  Item  17,  above,  must  be  changed  to  (AKO  WIFE  PERSON  (SEX  * 
FEMALE)  (MARITAL-STATUS  *  MARRIED)). 
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Many  other  transform -I  ons  are  needed  :o  arrive  at  the  Precise  Model  program  given 
below,  only  two  of  which  wl  11  be  dealt  with  here.  The  first  occors  In  Item  21.  above, 
which  attempts  to  find  a  hobby  In  common  between  the  husband  and  wife.  As  written.  It 
attempts  to  find  a  hobby  which  Is  the  value  of  the  HOBBY  relation  on  husbands  and 
wives*  Realization  that  husbands  and  wives  are  per  ions  and  thus,  that  the  HOBBY 
relation  Is  well-defined  In  that  regard,  occurs  automatically  within  the  typing 

mechanism  of  the  system.  However.InattemptlngtofIndthecommonhobby.it  must  be 

noticed  that  only  activities  can  be  the  value  of  HOBBY.  Hence  thl  s  pattern  must  be 
rewritten  to  look  for  an  activity  which  Is  in  common  between  the  husband  and  wife. 

More  indicative  of  the  types  of  problems  encountered  in  the  translation  process 

are  the  mechanisms  Involved  in  the  Interpretation  of  (HAS  PERSON  COMPATIBLE-MARRIAGE) 
In  Item  19.  The  system  starts  by  seeing  If  PERSON  and  COMPATIBLE-MARRIAGE  are  related 
by  the  HAS  relation.  They  are  not.  Now  the  system  knows  (1)  that  “HAS"  Is  used  very 
sloppily  in  English,  so  It  looks  to  see  how  PERSON  and  COMPATIBLE-MARRIAGE  are  related. 
COMPATIBLE-MARRIAGE  Is  A-K1N0-0F  marriage  and  MARRIAGE  Is  A-KIND-OF  the  event  of 
marrying.  MARRIAGE  Is  an  action  Involving  two  persons;  even  more.  It  asserts  that  the 
two  are  related  by  the  MARRIED  relation.  Hence.  If  the  relation  between  -MARRIAGE-  and 
-MARR1E0-  is  linguistically  known,  the  system  assumes  that  “HAS  MARRIAGE*  is  the  same 
as  -IS  MARRIED-*  Notice  that  MARRIEO  Is  being  used  in  two  ways-*  first,  as  an  attribute 
value  of  mar  1 1;  1  status.  „nd  second,  as  a  relation  between  two  people.  In  fact,  the 
marital  status  Is  being  farther  specified  by  whom  the  marriage  Is  with.  Finally,  there 
Is  the  Issue  of  when  the  condition  for  compatible  marriage  Is  applicable:  When  the 
marriage  occurred  or  when  the  question  was  asked?  In  addition,  notice  that  within  Item 

21,  above,  that  wife  and  husbend  are  not  existentially  quantified  but  relate  to  the 

partners  in  the  marriage.  hus,  from  the  Inferred  fact  that  the  person  is  married,  the 
system  must  pick  up  the  partner  and  use  that  pair  to  bind  the  husband  and  wife  by  type 
constraints  In  evaluating  this  condition.  The  result  of  this  expansion  is  shown  in  the 
MAKE-HAPPY  function  belov.  All  In  all,  the  chain  of  processing  required  in  the  loose 
to  precise  translation  is  rather  complex  and  Ill-defined. 


X 


(MAKEHAPPY 

[LAMBDA  (PERSON) 

(PROG  (PERSONS l  PERSONS2  PERSONS3  ACTIVITY) 

( ACM  J  EVE 

(OR  (WEALTH  PERSON  RICH) 

(AND  (MARRIED  PERSON  PERSGNS1) 

[LT 

(PLUS  [AGE  (PERSONS2  (SEX  *  MALE) 

(IN  (ONE-OF  PERSON  PERSONS1] 
5) 

(AGE  (PERSONS3  (SEX  *  FEMALE) 

(IN  (ONE-OF  PERSON  PERSONS! ] 
(HOBBY  PERSON  ACTIVITY) 

(HOBBY  PERSONS!  ACTIVITY))) 

THEN  (ASSERT  (EMOTION  PERSON  HAPPY]) 

(MARRY 

[LAMBDA  (PERSON  PERSCNSI) 

(PROG  (PERSONS 2  PER SGNS3) 

(CONSTRAIN  (NOT  (MARRIEO  PERSON  PERSONS2) ) 

(NOT  (MARRIEO  PERSONS!  PERSONS3  ) ) 

(NEQ  (SEX  PERSONS!) 

(SEX  PERSON))) 

(ASSERT  (MARRIED  PERSON  PERSONS!]) 

(CONSTRAINT OOO! 

[LAMBDA  (PERSON) 

(PROG  (PERSONS!  PERSCNS2 ) 

(NOT  (AND  (MARRIED  PERSON  PERSCNSI) 

(MARRIEO  PERSON  PERSCNS2]) 

(CONSTRAINT0002 
[LAMBDA  (PERSON) 

(PROG  NIL 

(NOT  (MARRIED  PERSON  PERSON]) 

(INFERENCEOOO! 

[LAMBDA  (PERSON  PERSONS! ) 

(PROG  NIL 

(IS  (MARRIED  PERSON  PERSCNSI) 

(THEN  (ASSERT  (MARRIED  PERSONS!  PERSON))) 

(ELSE]) 

( INFERENCE0002 
[LAMBDA  (PERSON) 

(PROG  NIL 

(IS  (GT  (NUMBER  (NETKORTH  PERSON  *)) 

1000000) 

(THEN  (ASSERT  (WEALTH  PEP  SON  RICH))) 

(ELSE!) 


CONCLUSION 


Althouqh  a  wealth  of  problems  remain  unsolved  (and  undiscovered),  a  clear 
direction  has  been  established.  Oomal n-1 ndependent  automatic  programming  has  been 
divided  Into  two  parts1  dialogue-driven  acquisition  of  the  domain  semantics,  and 
translation  of  Ill-defined  specifications  Into  a  precise  form.  Work  is  focusing  on 
creating  a  core  system  for  experimentation  and  on  explicating  the  transformations  In 
the  Domain  Acquisition  and  Model  Completion  modules.  The  Implementation  has  been 
started  and  the  Interpreter,  Data  Base  Handler,  and  Precise  Model  form  are  all  veil  'n 
hand.  An  Initial  knowledge  representation  has  been  selected. 

Despite  the  early  stage  of  the  project,  several  technical  contributions  have 
emerged  In  addition  to  the  overall  approach  outlined  above.  AP/1  supports  the 
Intermixing  of  patterns  to  be  Instantiated  and  expressions  to  be  evaluated. 
This  greatly  simplifies  program  control  structure  by  obviating  the  need  for  explicit 
low-level  search  and  control  mechanisms.  Knowledge  has  been  highly  structured 
through  the  strong  use  of  types  and  the  use  of  constraints  on  the  arguments  of  tuples. 
Finally,  techniques  have  been  described  for  converting  constraints  and  Inferences, 
as  well  as  actions.  Into  procedures  and  for  using  procedures  In  both  a  goal-directed 
and  applicative  manner. 
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